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DHCPv6 Prefix-Length Hint Issues 
Abstract 


DHCPv6 Prefix Delegation allows a client to include a prefix-length 
hint value in the IA_PD option to indicate a preference for the size 
of the prefix to be delegated, but it is unclear about how the client 
and server should act in different situations involving the prefix- 
length hint. This document provides a summary of the existing 
problems with the prefix-length hint and guidance on what the client 
and server could do in different situations. 
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Introduction 


DHCPv6 Prefix Delegation [RFC3633] 
prefix-length hint value in the message sent to the server to 
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allows a client to include a 


indicate a preference for the size of the prefix to be delegated. A 
prefix-length hint is communicated by a client to the server by 


including an IA_PD Prefix Option 


(IAPREFIX option), 


encapsulated in 


an IA_PD option, with the "IPv6 prefix" field set to zero and the 
length" field set to a non-zero value. The servers are free 
to ignore the prefix-length hint values depending on server policy. 


"prefix- 


However, 


degraded state) 


some clients may not be able to function 
when they’re provided with a prefix whose length is 
if the client is 


different from what they requested. For example, 


asking for a /56 and the server returns a /64, 


(or only ina 


the functionality of 


the client might be limited because it might not be able to split the 
prefix for all its interfaces. For other hints, 


for an explicit address, 


this might be less critical, 


such as requesting 
as it just 


helps a client that wishes to continue using what it used last time. 
The prefix-length hint directly impacts the operational capability of 


the client; thus, it should be given more consideration. 
[RFC3633] 


client perspective, 


is unclear about how the client and server should act in 
different situations involving the prefix-length hint. 
it should be able to use the prefix-length hint 


From the 


to signal to the server its real-time need and should be able to 
handle prefixes with lengths different from the prefix-length hint. 


This document provides guidance on what a client should do in 
From the server 


different situations to help it operate properly. 


perspective, 


the server is free to ignore the prefix-length hints 


depending on server policy; however, in cases where the server has a 
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policy for considering the hint, this document provides guidance on 
how the prefix-length hint should be handled by the server in 
different situations. 


Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Problem Description and Proposed Solutions 
Creation of Solicit Message 
Problem: 


The Solicit message allows a client to ask servers for prefixes and 
other configuration parameters. The client might want a different 
prefix length due to configuration changes, or it might just want the 
same prefix again after reboot. The client might also prefer a 
prefix of a specific length in case the requested prefix is not 
available. The server could decide whether to provide the client 
with the preferred prefix depending on server policy, but the client 
should be able to signal to the server its real-time need. 


The server usually has a record of the prefix it gave to the client 
during its most recent interaction. The best way to assure a 
completely new delegated prefix is to send a new IAID (Identity 
Association IDentifier) in the IA_PD (Identity Association for Prefix 
Delegation). However, this would require the client device to have 
persistent storage, because rebooting the device would cause the 
client to use the original IAID in the IA_PD. 


Solution: 


When the client prefers a prefix of a specific length from the 
server, the client MUST send a Solicit message using the same IAID in 
the IA_PD, include the preferred prefix-length value in the "prefix- 
length" field of the IAPREFIX option, and set the "IPv6é prefix" field 
to zero. This is an indication to the server that the client prefers 
a prefix of the specified length, regardless of what it received 
before. 


When the client wants the same prefix back from the server, it MUST 


send a Solicit message using the same IAID in the IA_PD, include the 
previously delegated prefix value in the "IPv6 prefix" field of the 
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TAPREFIX option, and include the length of the prefix in the "prefix-— 
length" field. This is an indication to the server that the client 
wants the same prefix back. 


When the client wants the same prefix back from the server and would 
prefer to accept a prefix of a specified length in case the requested 
prefix is not available, the client MUST send a Solicit message using 
the same IAID in the IA_PD, include the previously delegated prefix 
in one IAPREFIX option, and include the prefix-length hint in another 
IAPREFIX option. There is no requirement regarding the order of the 
two IAPREFIX options. 


Receipt of Solicit Message 
Problem: 


[RFC3633] allows a client to include a prefix-length hint in the 
Solicit message to signal its preference to the server. How the 
prefix-length hint should be handled by the server is unclear. The 
client might want a different prefix length due to configuration 
changes or it might just want the same prefix again after reboot. 
The server should interpret these cases differently. 


Many servers are configured to provide only prefixes of specific 
lengths to the client, for example, if the client requested for a /54 
but the server could only provide /30, /48, and /56. How should 
these servers decide which prefix to give to the client based on the 
prefix-length hint? 


Solution: 


Upon the receipt of Solicit message, if the client included only a 
prefix-length hint in the message, the server SHOULD first check its 
prefix pool for a prefix with a length matching the prefix-length 
hint value, regardless of the prefix record from previous 
interactions with the client. If the server does not have a prefix 
with a length matching the prefix-length hint value, then the server 
SHOULD provide the prefix whose length is shorter and closest to the 
prefix-length hint value. 


If the client included a specific prefix value in the Solicit 
message, the server SHOULD check its prefix pool for a prefix 
matching the requested prefix value. If the requested prefix is not 
available in the server’s prefix pool, and the client also included a 
prefix-length hint in the same IA_PD option, then the server SHOULD 
check its prefix pool for a prefix with a length matching the prefix- 
length hint value. If the server does not have a prefix with a 
length matching the prefix-length hint value, the server SHOULD 
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provide the prefix whose length is shorter and closest to the prefix- 
length hint value. 


If the server will not assign any prefixes to any IA_PDs ina 
subsequent Request from the client, the server MUST send an Advertise 
message to the client as described in Section 11.2 of [RFC3633]. 


3.3. Receipt of Advertise Message 
Problem: 


The server might not be able to honor the prefix-length hint due to 
server policy or lack of resources in its prefix pool. If the prefix 
length provided by the server in the Advertise message is different 
from what the client requested in the Solicit message, the question 
would be whether the client should use the provided prefix length or 
continue to ask for its preferred prefix length. There are certain 
situations in which the client could not operate properly if it used 
a prefix whose length is different from what it requested in the 
prefix-length hint. However, if the client ignores the Advertise 
messages and continues to solicit for the preferred prefix length, 
the client might be stuck in the DHCP process. Another question is 
whether the client should ignore other configuration parameters such 
as available addresses. 


Solution: 


If the client could use the prefixes included in the Advertise 
messages despite being different from the prefix-length hint, the 
client SHOULD choose the shortest prefix length that is closest to 
the prefix-length hint. The client SHOULD continue requesting the 
preferred prefix in the subsequent DHCPv6é messages as defined in 
Section 3.4 of this document. 


If the client sent a Solicit with only IA_PDs and cannot use the 
prefixes included in the Advertise messages, it MUST ignore the 
Advertise messages and continue to send Solicit messages until it 
gets the preferred prefix. To avoid traffic congestion, the client 
MUST send Solicit messages at defined intervals, as specified in 
[RFC7083]. 


If the client also solicited for other stateful configuration options 
such as IA_NAs and the client cannot use the prefixes included in the 
Advertise messages, the client SHOULD accept the other stateful 
configuration options and continue to request the desired IA_PD 
prefix in subsequent DHCPv6 messages as specified in [RFC7550]. 
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Creation of Renew/Rebind Message 
Problem: 


Servers might not be able to provide a prefix with the length equal 
to or shorter than the prefix-length hint. If the client decided to 
use the prefix provided by the server despite it being longer than 
the prefix-length hint but would still prefer the prefix-length hint 
originally requested in the Solicit message, there should be some way 
for the client to express this preference during Renew/Rebind. For 
example, if the client requested for a /60 but got a /64, the client 
should be able to signal to the server during Renew/Rebind that it 
would still prefer a /60. This is to see whether the server has the 
prefix preferred by the client available in its prefix pool during 
Renew/Rebind. [RFC3633] is not completely clear on whether the 
client is allowed to include a prefix-length hint in the Renew/Rebind 
message. 


Solution: 


During Renew/Rebind, if the client prefers a prefix length that is 
different from the prefix it is currently using, then the client 
SHOULD send the Renew/Rebind message with the same IA_PD, and include 
two IAPREFIX options, one containing the currently delegated prefix 
and the other containing the prefix-length hint. This is to extend 
the lifetime of the prefix the client is currently using, get the 
prefix the client prefers, and go through a graceful switch over. 


If the server is unable to provide the client with the newly 
requested prefix, but is able to extend lifetime of the old prefix, 
the client SHOULD continue using the old prefix. 


Receipt of Renew/Rebind Message 
Problem: 


The prefix preferred by the client might become available in the 
server’s prefix pool during Renew/Rebind, even though it was 
unavailable during Solicit. This might be due to a server 
configuration change or because some other client stopped using the 
prefix. 


The question is whether the server should remember the prefix-length 
hint the client originally included in the Solicit message and check 
it during Renew/Rebind to see if it has the prefix length the client 
preferred. This would require the server to keep extra information 
about the client. There is also the possibility that the client’s 

preference for the prefix length might have changed during this time 
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interval, so the prefix-length hint remembered by the server might 
not be what the client prefers during Renew/Rebind. 


Instead of having the server remember the prefix-length hint of the 
client, another option is for the client to include the prefix-length 
hint in the Renew/Rebind message. [RFC3633] is unclear about what 
the server should do if the client also included a prefix-length hint 
value in the Renew/Rebind message and whether the server could 
provide a different prefix to the client during Renew/Rebind. 


Solution: 


Upon the receipt of a Renew/Rebind message, if the client included in 
the IA_PD both an IAPREFIX option with the delegated prefix value and 
an IAPREFIX option with a prefix-length hint value, the server SHOULD 
check whether it could extend the lifetime of the original delegated 
prefix and whether it has any available prefix matching the prefix- 
length hint (or determine the closest possible to the prefix-length 
hint) within its limit. 


If the server assigned the prefix included in IA_PD to the client, 
the server SHOULD do one of the following, depending on its policy: 


1. Extend the lifetime of the original delegated prefix. 


2. Extend the lifetime of the original delegated prefix and assign a 
new prefix of the requested length. 


3. Mark the original delegated prefix as invalid by giving it 0 
lifetimes, and assign a new prefix of the requested length. This 
avoids the complexity of handling multiple delegated prefixes but 
may break all the existing connections of the client. 


4. Assign the original delegated prefix with 0 preferred-lifetime, a 
specific non-zero valid-lifetime depending on actual requirement, 
and assign a new prefix of the requested length. This allows the 
client to finish up existing connections with the original prefix 
and use the new prefix to establish new connections. 


5. Do not include the original delegated prefix in the Reply message, 
and assign a new prefix of the requested length. The original 
prefix would be valid until its lifetime expires. This avoids 
sudden renumbering on the client. 


If the server does not know the client’s bindings (e.g., a different 
server receiving the message during Rebind), then the server SHOULD 
ignore the original delegated prefix and try to assign a new prefix 
of the requested length. 
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It’s unnecessary for the server to remember the prefix-length hint 
the client requested during Solicit. It is possible that the 
client’s preference for the prefix length might have changed during 
this time interval, so the prefix-length hint in the Renew message is 
reflecting what the client prefers at the time. 


General Recommendation 


The recommendation to address the issues discussed in this document 
is for a client that wants (at least) to have a delegated prefix of a 
specific prefix length to always include an IAPREFIX option with just 
the prefix-length hint in addition to any IAPREFIX options it has 
included for each IA_PD in any Solicit, Request, Renew, and Rebind 
messages it sends. While a server is free to ignore the hint, 
servers that do not choose to ignore the hint should attempt to 
assign a prefix of the hint length (or assign the next closest length 
that does not exceed the hint) if one is available. Whether a server 
favors the hint or avoiding a renumbering event is a matter of server 
policy. 


Security Considerations 


This document provides guidance on how the clients and servers 
interact with regard to the DHCPv6é prefix-length hint. Security 
considerations in DHCP are described in Section 23 of [RFC3315]. 
Security considerations regarding DHCPv6 prefix delegation are 
described in Section 15 of [RFC3633]. 


TANA Considerations 
This document does not require any IANA actions. 
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